[pull] master from mozilla:master - #498

The rule rewrites `Math.max(C, Math.min(A, B))` to `MathClamp(A, C, B)`, always
taking the inner call's first operand as the value. `Math.min` is commutative,
so the value is just as often the second one, and then the fixer swaps it with
the upper bound: the result is `Math.min(C, v)`, which no longer applies the
lower bound at all. Both call sites the fixer rewrote hit that case, so the
max-outer patterns are now reported without a fix.

Reporting them still needs its own message. `Math.max(C, Math.min(A, B))` is
only `MathClamp(A, C, B)` when `C <= B`, and the rule can't know whether that
holds, so telling the reader to "use MathClamp" is wrong advice. The message
states the condition instead, and `useClamp` is left to the min-outer patterns,
which are exact.

In `PSStackBasedInterpreter.build` the outputs were therefore never clamped up
to the Range minimum. The interpreter runs whenever `PSStackToTree` can't turn
the program into a tree — a stack-shrinking `if`, or a `copy`/`index`/`roll`
whose operand isn't a constant — and it then let a Type 4 function return e.g.
-1.5 for a component declared as `/Range [0 1]`.

In `SplitView.#clampFirstSize` the first pane's size was never clamped up to
`#minSize`: dragging the resizer past it wrote a negative `flexGrow`.

The existing range-clamping test only checked the upper bound, which is the one
the wrong operand order preserves.